-
Notifications
You must be signed in to change notification settings - Fork 714
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: make feature flags consistent #3921
Conversation
480bc43
to
2a56f02
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! Only other thought- it might be nice to put a couple sentences in DEVELOPMENT.md about how to add feature flags.
Yeah that's a good idea. Although I'd prefer to do it separately from the fix here. |
2a56f02
to
948c19d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great idea!
Did you do any manual testing outside of the CI? You're making a lot of build changes, so I'm a little worried.
# Kyber Round-3 code has several different optimizations which require | ||
# specific compiler flags to be supported by the compiler. | ||
# So for each needed instruction set extension we check if the compiler | ||
# supports it and set proper compiler flags to be added later to the | ||
# Kyber compilation units. | ||
if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^(x86_64|amd64|AMD64)$") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't you expect the compilation attempt to fail if the flags aren't supported? Or are they just ignored?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect it to fail, yeah. But I also didn't want to change the overall logic from what was there so I kept it.
endif() | ||
feature_probe_result(S2N_KYBER512R3_AVX2_BMI2 ${S2N_KYBER512R3_AVX2_BMI2}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I missing something, or is this only supported via cmake, not for the bindings or make? Is that a problem?
But if that's right, then the same problem for S2N_STACKTRACE seems more serious...
That's fair. I went through all of our existing CI jobs to make sure that the features are enabled that should be enabled for that particular environment. I also did a bunch of manual review for each feature probe to make sure I didn't miss anything. If you have any other ideas I'm open! |
TODO:
|
948c19d
to
9227bd9
Compare
|
I ended up just adding stacktrace support to the Makefile, since it does support it today; just no option to disable it: Lines 187 to 190 in b9c4d60
|
The |
CFLAGS += $(SUPPORTED_FEATURES) | ||
DEFAULT_CFLAGS += $(SUPPORTED_FEATURES) | ||
CPPCFLAGS += $(SUPPORTED_FEATURES) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How were CFLAGS and CPPCFLAGS being set before? Were they being set before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They weren't! Meaning anything using those wasn't getting any feature flags. I ran into this with the fuzz test while implementing #3798.
Description of changes:
We currently have 3 different ways to build the library: CMake, Make, and Cargo. Currently each method is required to maintain its own list of feature probes, which can easily get out of date.
This PR, instead, dynamically compiles a list of feature probes from the
tests/features
directory and uses the name of the file to define the symbol in the build (if the feature probe was successful). This makes adding a feature probe as easy as creating a.c
and.flags
file.Call-outs:
While implemented the dynamic feature probes in Cargo, I noticed that the feature probes were actually broken so no features were being enabled there at all. This PR fixes that issue.
I also noticed that the fuzz builds were not picking up any feature probe flags. After this change, they now are correctly enabled:
Testing:
Since the feature probing is handled in a consistent way, so is the logging of which features were enabled:
You can also see the output in the
flags.make
:By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.